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Abstract 

We aim for composing algorithmic music in an in- 
teractive way with multiple participants. To this 
end we have developed an interpreter for a sub- 
language of the non-strict functional programming 
language Haskell that allows the modification of a 
program during its execution. Our system can be 
used both for musical live-coding and for demon- 
stration and education of functional programming. 
Keywords: Live coding, MIDI, Functional 
programming, Haskell 



1 Introduction 

It is our goal to compose music by algorithms. 
We do not want to represent music as a se- 
quence of somehow unrelated notes as it is 
done on a note sheet. Instead we want to de- 
scribe musical structure. For example, we do 
not want to explicitly list the notes of an ac- 
companiment but instead we want to express 
the accompaniment by a general pattern and 
a sequence of harmonies. A composer who 
wants to draw a sequence of arbitrary notes 
might serve as another example. The com- 
poser does not want to generate the random 
melody note by note but instead he wants to 
express the idea of randomness. Following 
such a general phrase like "randomness" the 
interpreter would be free to play a different 
but still random sequence of notes. 

The programmer shall be free to choose the 
degree of structuring. For instance, it should 
be possible to compose a melody manually, 
accompany it using a note pattern following a 
sequence of user defined harmonies and com- 
plete it with a fully automatic rhythm. 



With a lot of abstraction from the actual 
music it becomes more difficult to predict the 
effect of the programming on the musical re- 
sult. If you are composing music that is not 
strictly structured by bars and voices then it 
becomes more difficult to listen to a certain 
time interval or a selection of voices for test- 
ing purposes. Also, the classical edit-compile- 
run loop hinders creative experiments. Even 
if the music program can be compiled and 
restarted quickly, you must terminate the run- 
ning program and thus the playing music and 
you must start the music from the beginning. 
Especially if you play together with other mu- 
sicians this is unacceptable. 

In our approach to music programming we 

-strictj_ 



non- 



program- 



use a purely functional 
ming language [6], that is almost a subset of 
Haskell 98 [11]. Our contributions to live mu- 
sic coding are concepts and a running system 
offering the following: 



algorithmic music composition where the 
program can be altered while the music 



is playing (Section 2.1) 



simultaneous contributions of multiple 
programmers to one song led by a con- 



ductor (Section 2.2). 



1 All terms set in italics are explained in the glossary 
on page|9] In the PDF they are also hyperlinks. 
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2 Functional live program- 
ming 

2.1 Live coding 

We want to generate music as a list of MIDI 
events [9], that is events like "key pressed", 
"key released" , "switched instrument" , "knob 
turned" and wait instructions. A tone with 
pitch C-5, a duration of 100 milliseconds and 
an average force shall be written as: 

main = 

[ Event (On c5 normalVelocity) 
, Wait 100 

, Event (Off c5 normalVelocity) 

] ; 

c5 = 60 ; 

normalVelocity = 64 ; 

Using the list concatenation "++" we can al- 
ready express a simple melody. 

main = 

note qn c ++ note qn d ++ 
note qn e ++ note qn f ++ 
note hn g ++ note hn g ; 

note duration pitch = 

[ Event (On pitch normalVelocity) 
, Wait duration 

, Event (Off pitch normalVelocity) 

] ; 



qn = 200 ; 
hn = 2*qn 



— quarter note 

— half note 



c = 60 
d = 62 
e = 64 
f = 65 
g = 67 
normalVelocity = 64 ; 

We can repeat this melody infinitely by start- 
ing it again when we reach the end of the 
melody. 



main = 

note qn c ++ note qn d ++ 
note qn e ++ note qn f ++ 
note hn g ++ note hn g ++ main ; 

Please note, that this is not a plain recursion, 
but a so called \co-recursion\ If we define the 
list main this way it is infinitely long but if 
we expand function applications only when 
necessary then we can evaluate it element by 
element. Thanks to this evaluation strategy 



(in a sense lazy evaluation without sharing ) 



we can describe music as pure list of events. 
The music program does not need, and cur- 
rently cannot, call any statements for interac- 
tion with the real world. Only the interpreter 
sends MIDI messages to other devices. 

In a traditional interactive interpreter like 
the GHCi0 we would certainly play the music 
this way: 

Prelude> playMidi main 

If we would like to modify the melody we 
would have to terminate it and restart the 
modified melody. In contrast to this we want 
to alter the melody while the original melody 
remains playing and we want to smoothly lead 
over from the old melody to the new one. In 
other words: The current state of the inter- 
preter consists of the program and the state 
of the interpretation. We want to switch the 
program, but we want to keep the state of in- 
terpretation. This means that the interpreter 
state must be stored in a way such that it 
stays sensible even after a program switch. 

We solve this problem as follows: The 
interpreter treats the program as a set of 
term rewriting rules, and executing a program 
means to apply rewrite rules repeatedly until 
the start term main is expanded far enough 
that the root of the operator tree is a terminal 



symbol (here a constructor). For the musical 



application the interpreter additionally tests 
whether the root operator is a list constructor, 
and if it is the constructor for the non-empty 



2 Glasgow Haskell Compiler in interactive mode 
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list then it completely expands the leading el- 
ement and checks whether it is a MIDI event. 
The partially expanded term forms the state 
of the interpreter. For instance, while the 
next to last note of the loop from above is 
playing, that is, after the interpreter has sent 
its NoteOn event, the current interpreter state 
would look like: 

Wait 200 : 

(Event (Off g normalVelocity) : 
(note hn g ++ main) ) 

The interpreter will rewrite the current ex- 
pression as little as possible, such that the 
next MIDI event can be determined. On the 
one hand this allows us to process a formally 
infinite list like main, and on the other hand 
you can still observe the structure of the re- 
maining song. E.g. the final call to main 
is still part of the current term. If we now 
change the definition of main then the modi- 
fied definition will be used when main is ex- 
panded next time. This way we can alter the 
melody within the loop, for instance to: 

main = 

note qn c ++ note qn d ++ 
note qn e ++ note qn f ++ 
note qn g ++ note qn e ++ 
note hn g ++ main ; 

But we can also modify it to 
main = 

note qn c ++ note qn d ++ 
note qn e ++ note qn f ++ 
note hn g ++ note hn g ++ loopA ; 

in order to continue the melody with another 
one called loopA after another repetition of 
the main loop. 

We want to summarise that the meaning of 
an expression can change during the execu- 
tion of a program. That is, we give up a fun- 
damental feature of functional programming, 



namely referential transparency 



We could implement the original loop using 
the standard list function cycle 

main = 
cycle 

( note qn c ++ note qn d ++ 
note qn e ++ note qn f ++ 
note hn g ++ note hn g ) ; 

and if cycle is defined by 

cycle xs = xs ++ cycle xs ; 

then this would be eventually expanded to 

( note qn c ++ note qn d ++ 
note qn e ++ note qn f ++ 
note hn g ++ note hn g ) 

++ 

cycle 

( note qn c ++ note qn d ++ 
note qn e ++ note qn f ++ 
note hn g ++ note hn g ) ; 

Using this definition we could leave the loop 
only by changing the definition of cycle. But 
such a change would affect all calls of cycle 
in the current term. Further, in a rigor- 
ous module system without import cycles it 
would be impossible to access functions of the 
main module from within the standard mod- 
ule List that defines the cycle function. But 
this would be necessary in order to not only 
leave the cycle loop but to continue the pro- 
gram in the main module. 

From this example we learn that a man- 
ually programmed loop in the form of 
main = ... ++ main has advantages over a 
loop function from the standard library, be- 
cause the manual loop provides a position 
where we can insert new code later. 

Additionally to the serial composition of 
musical events we need the parallel com- 
position for the simultaneous playback of 
melodies, rhythms and so on. At the level 
of MIDI commands this means that the com- 
mands of two lists must be interleaved in the 
proper way. For details we refer the reader to 
the implementation of "= : =" . 
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2.1.1 User interface 

The graphical user interface is displayed in 
Figure [TJ In the upper left part the user enters 
the program code. Using a keyboard short- 
cut he can check the program code and trans- 
fer it to the buffer of the interpreter. The 
executed program is shown in the upper right 
part. In this part the interpreter highlights 
the function calls that had to be expanded in 
order to rewrite the previous interpreter term 
into the current one. This allows the user to 
trace the melody visually. The current term of 
the interpreter is presented in the lower part 
of the window. The texts in the figure are 
essentially the ones from our introductory ex- 
ample. 



File Execution Window 

Bool Enum Function Integer LAC List List. Basic ListLive Midi Prelude Tuple 



nodule LAC where 

import Midi 

import List 

nain = 

note qn c ++ note qn d - 

note qn e ++ note qn f - 

note hn g ++ note hn g - 



qn = 200 ; 
= 2*qn 



rJ = 62 
E - 64 
f = 65 



-- quarter note 
-- half note 



module LAC where 



import Midi 
import List 



note qn c ++ note qn d ■ 
note qn e ++ note qn f - 
note hn g ++ note hn g ■ 



\ = 200 : 
= 2*qn 



d = €2 
e - 64- 
f = 65 



-- quarter note 
-- half note 



| (Wait 200) 



■ (: (noteoff 60) []) 
(++ (note qn d) 
(++ [note qn e) 

C++ (note qn f) C++ (note hn g) (++ (note hn g) main)))))) 



interpreter in single step mode, waiting tor next step 



Figure 1: The running interpreter 

Our system can be run in three modes: 
"real time" , "slow motion" and "single step" . 
The real-time mode plays the music as re- 
quired by the note durations. In contrast to 
that the other two modes ignore the wait in- 
structions and insert a pause after every ele- 
ment of the MIDI event list. These two modes 
are intended for studies and debugging. You 
may also use them in education if you want 
to explain how an interpreter of a non-strict 
functional language works in principle. 

We implemented the interpreter in Haskell 



using the Glasgow Haskell Compiler GHC 
[12] . and we employ Wx Widgets [13] for the 
graphical user interface. Our interpreted lan- 
guage supports pattern matching, a set of 
predefined infix operators, higher order func- 
tions, and partial function application. For 
the sake of a simple implementation we devi- 
ate from Haskell 98 in various respects: Our 
language is dynamically and weakly typed: 
It knows "integer" , "text" and l \constructor\ . 
The parser does not pay attention to layout 
thus you have to terminate every declaration 
with a semicolon. Several other syntactic fea- 
tures of Haskell 98 are neglected, including 
list comprehensions, operator sections, do no- 
tation, "let" and "case" notation, and custom 
infix operators. I/O operations are not sup- 
ported as well. 

2.2 Distributed coding 

Our system should allow the audience to con- 
tribute to a performance or the students to 
contribute to a lecture by editing program 
code. The typical setup is that the speaker 
projects the graphical interface of the se- 
quencer at the wall, the audience can listen 
to music through loud speakers, and the par- 
ticipants can access the computer of the per- 
former via their browsers and wireless net- 
work. 

Our functional language provides a simple 
module system. This helps the performer to 
divide a song into sections or tracks and to 
put every part in a dedicated module. Then 
he can assign a module to each participant. 
This is still not a function of the program, but 
must be negotiated through other means. For 
instance the conductor might point to people 
in the audience. Additionally the performer 
can insert a marker comment that starts the 
range of text that participants can edit. The 
leading non-editable region will usually con- 
tain the module name, the list of exported 
identifiers, the list of import statements, and 
basic definitions. This way the performer can 
enforce an interface for every module. 
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A participant can load a module into his 
web browser. The participant sees an HTML 
page showing the non-editable header part as 
plain text and the editable region as an ed- 
itable text field, (cf. Figure [2]) After editing 
the lower part of module he can submit the 
modified content to the server. The server 
replaces the text below the marker comment 
with the submitted text. Subsequently the 
new module content is checked syntactically 
and on success it is loaded into the interpreter 
buffer. In case of syntax errors in the new 
code the submitted code remains in the edi- 
tor field. The performer can inspect it there 
and can make suggestions for fixes. 

jVj? HaskeLLLive Sequencer- module LAC- Konqueror g g * 

* http://Localho£t:8080/LAC €J v' ^ [>>'J v ] 0*j 

• LAC 

• Function 

• Integer module LAC where 
- LAC 

• List import Midi 

• JJsLBask import List 

• Li st Live 

. Midi c = 60 ; d = 62 ; e = 64 ; f = 65 ; g = 67 ; 

• Prelude qn = 200 ; hn = 2*qn ; 

• Tuple 



main - 










note 


qn c 


++ note 


qn 


d ++ 


note 


qn e 


++ note 


qn 


f ++ 


note 


hn g 


++ note 


hn 


g ++ main ; 



submit 



Figure 2: Accessing a module via HTTP 

Generally it will not be possible to start 
composition with many people from scratch. 
However, the performer can prepare a session 
by defining a set of modules and filling them 
with basic definitions. For instance he can 
provide a function that converts a list of ze- 
ros and ones into a rhythm, or a list of integers 
into a chord pattern or a bass line. By provid- 
ing a meter and a sequence of harmonies he 
can assert that the parts contributed by the 
participants fit together loosely. In this appli- 
cation the performer no longer plays the role 
of the composer but the role of a conductor. 



2.3 Timing 



For a good listening experience we need pre- 
cise timing for sending MIDI messages. A 
naive approach would be to send the mes- 
sages as we compute them. I.e. in every step 
we would determine the next element in the 
list of MIDI events. If it is a wait instruction 
then we would wait for the desired duration 
and if it is a MIDI event then we would send 
it immediately. However this leads to audible 
inaccuracies due to processor load caused by 
term rewriting, garbage collection and GUI 
updates. 

We are using the ALSA sequencer interface 
for sending MIDI messages. It allows us to 
send a MIDI message with a precise but fu- 
ture time stamp. However we still want that 
the music immediately starts if we start the 
interpreter and that the music immediately 
stops if we stop it and that we can also con- 
tinue a paused song immediately. We achieve 
all these constraints the following way: We 
define a latency, say d milliseconds. The in- 
terpreter will always compute as many events 
in advance until the computed time stamps 
are d milliseconds ahead of current time. This 
means that the interpreter will compute a lot 
without waiting when it is started. It will 
not immediately send a MIDI message be- 
cause it needs to compute it first. This in- 
troduces a delay, sometimes audible, but we 
cannot do it faster. When the user pauses the 
interpreter, we halt the timer of our outgoing 
ALSA queue. This means that the delivery of 
messages is immediately stopped, but there 
are still messages for the next d milliseconds 
in the queue. If the interpreter is continued 
these messages will be send at their scheduled 
time stamps. If the interpreter is stopped we 
simply increase the time of the ALSA queue 
by d milliseconds in order to force ALSA to 
send all remaining messages. 
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3 Related work 

Algorithmic composition has a long tradition. 
The musical dice games by Mozart and the 
Illiac Suite [I] might serve as two popular ex- 
amples here. Further on, the Haskore project 
(now Euterpea) [5] provides a method for mu- 
sic programming in Haskell. It also lets you 
control synthesisers via MIDI and it supports 
the generation of audio files via CSound, Su- 
perCollider or pure Haskell audio signal syn- 
thesis. Like our approach, Haskore relies 
upon lazy evaluation which allows for an el- 
egant definition of formally big or even in- 
finite songs while its interpretation actually 
consumes only a small amount of memory. 
However, the creative composition process is 
made more difficult by the fact that you can 
listen to a change to a song only after ter- 
minating the old song and starting the new 
one. In a sense, our system is an interactive 
variation of Haskore. 

So-called functional reactive programming 
is a very popular approach for programming 
of animations, robot controls, graphical user 
interfaces and MIDI processing in Haskell 
[3]. Functional reactive programming mim- 
ics working with a time ordered infinite list 
of events. But working with actual lazy lists 
leads to fundamental problems in real-time 
processing, e.g. if a stream of events is divided 
first but merged again later. This is a prob- 
lem that is solved by functional reactive pro- 
gramming libraries. The advantage of func- 
tional reactive MIDI processing compared to 
our approach is that it allows the processing 
of event input in realtime. The disadvantage 
is that usually you cannot alter a functional 
reactive program during execution. 

Erlang is another functional (but not purely 
functional) programming language that ac- 
cepts changes to a program while the program 
is running pQ. Erlang applies eager evalua- 
tion. That is, in Erlang you could not de- 
scribe a sequence of MIDI commands by a 
lazy list of constructors. Instead you would 
need iterators or similar tools. You can in- 



sert new program code into a running Erlang 
programming in two ways: Either the running 
program runs functions (e.g. lambda expres- 
sions) that it receives via messages or you re- 
place an Erlang module by a new one. If you 
upload a new Erlang module then the old ver- 
sion is kept in the interpreter in order to con- 
tinue the running program. Only calls from 
outside the module jump into the code of the 
new module, but by qualification you can also 
simulate an external call from within the re- 
placed module. That is, like in our approach, 
you need dedicated points (external calls or 
calls of functions received via messages) where 
you can later insert new code. 

Summarised, our approach for changing 
running programs is very similar to "Hot 
Code loading" in Erlang. However, the non- 
strict evaluation of our interpreter implies 
that considerable parts of the program are 
contained in the current term. These are not 
affected immediately by a change to the pro- 
gram. This way we do not need to hold two 
versions of a module in memory for a smooth 
transition from old to new program code. In 
a sense, Erlang's external calls play the role 
of our top-level functions. 

Musical live coding, i.e. the programming 
of a music generating program, while the mu- 
sic is playing, was in the beginning restricted 
to special purpose languages like SuperCol- 
lider/SCLang [7] and ChucK [H] and their 
implementations. With respect to program 
control these languages adhere to the impera- 
tive programming paradigm and with respect 
to the type system they are object oriented 
languages. The main idea in these languages 
for creating musical patterns is constructing 
and altering objects at runtime, where the ob- 
jects are responsible for sending commands to 
a server for music generation. 

Also in our approach the sound generation 
runs parallelly to the interpreter and it is 
controlled by (MIDI) commands. However, 
in our approach we do not program how to 
change some runtime objects but instead we 
modify the program directly. 
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In the meantime also Haskell libraries for 
live coding are available, like Tidal ([8]) and 
Conductive ([2]). They achieve interactivity 
by running commands from the interactive 
Haskell interpreter GHCi. They are similar 
to SCLang and ChucK in the sense that they 
maintain and manipulate (Haskell) objects at 
runtime, that in turn control SuperCollider or 
other software processors. 

4 Conclusions and future 
work 

Our presented technique demonstrates a new 
method for musical live coding. Maybe it 
can also be transferred to the maintenance 
of other long-running functional programs. 
However, we have shown that the user of the 
live-sequencer must prepare certain points for 
later code insertion. Additionally our system 
must be reluctant with automatic optimisa- 
tions of programs since an optimisation could 
remove such an insertion point. If you mod- 
ify a running program then functions are no 
longer refer entially transparent, that is, we 



give up a fundamental feature of functional 
programming. 

Type system A static type checker would 
considerably reduce the danger that a run- 
ning program must be aborted due to an ill- 
typed or inconsistent change to the program. 
The type checker would not only have to test 
whether the complete program is type correct 
after a module update. Additionally it has to 
test whether the current interpreter term is 
still type correct with respect to the modified 
program. 

A type checker is even more important for 
distributed composition. The conductor of 
a multi-user programming session could de- 
clare type signatures in the non-editable part 
of a module and let the participants imple- 
ment the corresponding functions. The type 
checker would assert that participants could 
only send modifications that fit the rest of the 



song. 

Evaluation strategy Currently our inter- 
preter is very simple. The state of the 
interpreter is a term that is a pure tree. 



This representation does not allow for shar- 
\ing E.g. if f is defined by f x = x:x: [] 
then the call f (2+3) will be expanded to 
(2+3) : (2+3) : [] . However, when the 
first list element is evaluated to 5, the second 
element will not be evaluated. I.e. we obtain 
5 : (2+3) : [] and not 5 : 5 : [] . Since 
the term is a tree and not a general graph we 
do not need a custom garbage collector. In- 
stead we can rely upon the garbage collector 
of the GHC runtime system that runs our in- 
terpreter. If a sub-term is no longer needed it 
will be removed from the operator tree and 
sooner or later it will be detected and de- 
allocated by the GHC garbage collector. 

Even a simple co-recursive definition like 
that of the sequence of Fibonacci numbers 



main = fix fibs 

fibs x = : 1 : zipWith (+) x (tail x) 
fix f = f (fix f) 

leads to an unbounded growth of term size 
with our evaluation strategy. In the future 
we want to add more strategies like the graph 
reduction using the STG machine [TO]. This 
would solve the above and other problems. 
The operator tree of the current term would 
be replaced by an operator graph. The ap- 
plication of function definitions and thus the 
possibility of live modifications of a definition 
would remain. However, in our application 
there is the danger that program modifica- 
tion may have different effects depending on 
the evaluation strategy. On the one hand, the 
sharing of variable values at different places in 
the current term would limit the memory con- 
sumption in the Fibonacci sequence defined 
above, on the other hand it could make it im- 
possible to respect a modification of the called 
function. 

Our single step mode would allow the 
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demonstration and comparison of evaluation 
strategies in education. 

Currently we do not know, whether and 
how we could embed our system, including 
live program modifications, into an existing 
language like Haskell. This would simplify 
the study of the interdependence between pro- 
gram modifications, optimisations and evalu- 
ation strategies and would provide many syn- 
tactic and typing features for free. 

For this purpose we cannot use an interac- 
tive Haskell interpreter like GHCi directly: 

• GHCi does not let us access or even mod- 
ify a running program and its internal 
representation is optimized for execution 
and it is not prepared for changes to the 
running program. 

• GHCi does not allow to observe execu- 
tion of the program, and thus we could 
not highlight active parts in our program 
view. 

• GHCi does not store the current inter- 
preter state in a human readable way 
that we can show in our display of the 
current term. 

Nonetheless, we can imagine that it is pos- 
sible to write an embedded domain specific 
language. That is, we would provide func- 
tions that allow to program Haskell expres- 
sions that only generate an intermediate rep- 
resentation that can then be interpreted by a 
custom interpreter. 

Highlighting We have another interesting 
open problem: How can we highlight program 
parts according to the music? Of course, we 
would like to highlight the currently played 
note. Currently we achieve this by highlight- 
ing all symbols that were reduced since the 
previous pause. However if a slow melody is 
played parallelly to a fast sequence of con- 
troller changes this means that the notes of 
the melody are highlighted only for a short 



time, namely the time period between con- 
troller changes. Instead we would expect that 
the highlighting of one part of music does not 
interfere with the highlighting of another part 
of the music. 

We can express this property formally: Let 
the serial composition operator ++ and the 
parallel composition operator = := be defined 
both for terms and for highlighting graphics. 
Consider the mapping highl, that assigns a 
term to its visualisation. Then for every two 
musical objects a and b it should hold: 

highl (a ++ b) = highl a ++ highl b 
highl (a =:= b) = highl a =:= highl b 

If you highlight all symbols whose expan- 
sion was necessary for generating a Note On 
or NoteOff MIDI command, then we obtain 
a function highl with these properties. How- 
ever this causes accumulation of highlighted 
parts. In 

note qn c ++ note qn d ++ 
note qn e ++ note qn f 

the terms note qn c and note qn d would 
still be highlighted if note qn e is played. 
The reason is that note qn c and note qn d 
generate finite lists and this is the reason that 
note qn e can be reached. That is the expan- 
sion of note qn c and note qn d is necessary 
to evaluate note qn e. 

JACK support In the future our system 
should support JACK in addition to ALSA. It 
promises portability and synchronous control 
of multiple synthesisers. 

Beyond MIDI MIDI has several limita- 
tions. For example, it is restricted to 16 chan- 
nels. In the current version of our sequencer 
the user can add more ALSA sequencer ports 
where each port adds 16 virtual MIDI chan- 
nels. E.g. the virtual channel 40 addresses 
the eigth channel of the second port (zero- 
based counting). MIDI through wires is lim- 
ited to sequential data, that is, there can- 
not be simultaneous events. In contrast to 
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that the ALSA sequencer supports simulta- 
neous events and our Live sequencer supports 
that, too. Pitches in MIDI are designed to- 
wards 12-tone equal temperament. You have 
to use pitch-bending or different interpreta- 
tion of pitches in order to relax this bias. 

Thus the use of MIDI is twofold: On the 
one hand it is standard in hardware synthe- 
sisers and it is the only music control protocoll 
supported by JACK. On the other hand it has 
limitations. The Open Sound Control proto- 
col lifts many of these limitations. It should 
also be relatively simple to add OSC support, 
but currently it has low priority. 

We could also think about direct support of 
software synthesisers like Csound and Super- 
Collider. However we have intentionally cho- 
sen to separate the music controller from the 
music generator. This seems to be more mod- 
ular and keeps the sequencer simple. Anyway 
we should think about how to enable Live- 
sequencer modules to send e.g. sound algo- 
rithms to Csound or SuperCollider. This way, 
a Live-sequencer song could carry all informa- 
tion for reproduction of a song. 
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A Glossary 

A constructor is, mathematically speak- 
ing, an injective function and, operationally 



speaking, a way to bundle and wrap other 
values. E.g. a list may be either empty, 
then it is represented by the empty list con- 
structor [] , or it has a leading element, then 
it is represented by the constructor : for 
the non-empty list. For example, we repre- 
sent a list containing the numbers 1, 2, 3 by 
1 : (2 : (3 : [] ) ) , or more concisely by 
1:2:3: [] , since the infix : is right- 
associative. 

Co-recursion is a kind of inverted recur- 
sion. Recursion decomposes a big problem 
into small ones. E.g. the factorial "!" of a 
number can be defined in terms of the facto- 
rial of a smaller number: 



1 



: n 







■/)! 



n • (n — 1)! : n > 



A recursion always needs a base case, that 
is, a smallest or atomic problem that can be 
solved without further decomposition. 

In contrast to this, co-recursion solves a 
problem assuming that it has already solved 
the problem. It does not need decomposition 
and it does not need a base case. E.g. a co- 
recursive definition of an infinite list consist- 
ing entirely of zeros is: zeros = : zeros 

Lazy evaluation is an evaluation strategy 
for lnon- strict semantics\ An alternative name 
is "call-by- need" . It means that the evalua- 
tion of a value is delayed until it is needed. 
Additionally it provides \sharing of common 
results. 

Non-strict semantics means that a func- 
tion may have a defined result even if it is 
applied to an undefined value. It is a purely 
mathematical property that is independent 
from a particular evaluation strategy. 

E.g. the logical "and" operator && in the 
C programming language is non-strict. In a 
strict semantics the value of p && *p would 
be undefined if p is NULL, because then *p 
would be undefined. However, && allows the 
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second operand to be undefined if the first one 
is false. 

Referential transparency means that 
function values depend entirely on their ex- 
plicit inputs. You may express it formally by: 



Vx,y : 



V fix) = f(y) 



For mathematical functions this is always 
true, e.g. whenever x = y it holds sinx = 
siny. However for sub- routines in impera- 
tive languages this is not true, e.g. for a 
function readByte that reads the next byte 
from a file, readByte (fileA) may differ from 
readByte (fileB) although fileA = fileB. 

Sharing means that if you read a variable 
multiple times it is still computed only once 
and then stored for later accesses. 
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